home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / misc-part1 / 1785 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  5.2 KB

  1. Path: homer.louisville.edu!krsear01
  2. From: krsear01@homer.louisville.edu (Kendall R. Sears)
  3. Newsgroups: comp.sys.amiga.misc
  4. Subject: Re: OS features
  5. Date: 16 Jan 1996 14:25:44 GMT
  6. Organization: University of Louisville, Louisville KY USA
  7. Distribution: inet
  8. Message-ID: <4dgch8$rkf@hermes.louisville.edu>
  9. References: <92747544038@PAPA.NORTH.DE> <4b3h9s$1st@alterdial.UU.NET> <m4d20p0mn2v.fsf@freud.hut.fi>
  10. NNTP-Posting-Host: homer.louisville.edu
  11. X-Newsreader: TIN [version 1.2 PL2]
  12.  
  13.  
  14. > >What I propose is a system to segregate the system memory into 3 parts:
  15. > >  1) an area for the OS that is protected from writes by user processes
  16. > >  2) an area for user code that is write protected
  17. > >  and
  18. > >  3) a "public" area where the data segments of programs are stored as well
  19. > >     as message ports, and other data that need to be accessed by multiple
  20. > >     programs.
  21.  
  22. > Something like MEMF_PUBLIC, MEMF_PROTECTED and MEMF_PRIVATE?  I have
  23.  
  24. Well, sort of.  I have monitored several discussions where flags of that sort
  25. were batted around and in the end, for the sake of compatibility, those were
  26. rejected.  What I was thinking was more along the lines of modifying LoadSeg()
  27. to put the code segments into protected memory and everything else in a public
  28. area.  Obviously, flags of the above sort would/could be useful for future
  29. programs.
  30.  
  31. > been toying around with a similar idea.  Code space would be allocated
  32. > from protected memory space, so that crazed programs could not write
  33. > over existing code (and self-modifying code works badly
  34. > anyway). Private data would be specifically protected with the
  35. > MEMF_PRIVATE flag and the application programmer would know upon
  36. > writing the code that the data in it cannot be shared with other
  37. > tasks. Old programs would be given MEMF_PUBLIC-type memory always so
  38. > that they would continue to work, and crash each other. If the OS
  39. > contained more checks against rogue pointers we could have a very
  40. > stable OS with a very high degree compatability.
  41.  
  42. Very close to what I was saying.  Self modifying code is illegal, therefore we
  43. just don't support it... period.  Otherwise, LoadSeg() could put the code
  44. segments of even old programs into protected memory, as long as the data is 
  45. available then most programs should be unaffected.
  46.  
  47. > >Obviously, if a rogue program goes tromping through area 3 data could be
  48. > >corrupted, but correctly written programs check packet validity upon receipt
  49. > >to their port(s) and should be able to reject bad data, in the case where they
  50.  
  51. > This means the OS also should be more picky about the data it gets.
  52.  
  53. Should.  If type checking (use the lh_Type/ln_Type fields folks!) were added
  54. to the OS then things could become more stable, but that's not a guarantee.
  55. Usually, bad pointers to the OS point to $0 and enforcer has done wonders for
  56. developers to find those (and also wonders for users to keep the system up!)
  57. and I don't see why enforcer type protection shouldn't be added to the OS.
  58.  
  59. > >Obviously, use of the MMU to change the status of memory sections will create
  60. > >some slowdown, but since most, if not all, changes will occur with a context
  61. > >switch this probably won't be noticed.
  62.  
  63. > I bet every serious Amiga programmer would be ready to live with it. I
  64. > know I would =)
  65.  
  66. Every programmer I know wouldn't care about a few cycles wasted... especially
  67. when the cycles wasted are compared to the time wasted to recover from a crash.
  68. It's the /<0d3rz that have problems with it, but most of them toss out the OS
  69. anyway.
  70.  
  71. > >We could even take this a little farther... Assume that an Area 3 is set up
  72. > >for each process, when a process disappears (for any reason) the OS could
  73. > >call a DeletePool() on the area to recover most allocated memory (assuming,
  74. > >of course, that AllocMem() et al. is changed to call the pool functions.)
  75. > >The OS could either use an age mechanism or a task that occasionally runs
  76. > >the pools looking for headers that contain ids that no longer exist.
  77.  
  78. > Resource tracking?  Would be fun... I'd also like to see an ability to
  79. > reduce memory trashing, but this should come "almost free" with a VM
  80. > solution. 
  81.  
  82. Resource tracking: of a sort.  Technically, it's not.  To track resources would
  83. involve listing all screens/windows/layers/temprasts/... and freeing those.  My
  84. method above would not even attempt to close/free screens/windows nor would it
  85. remove resources from system lists. My method would only free memory held in
  86. the pools that have (expired|no process) and return that memory to the system.
  87. It'd be up to Intuition to handle the cases for itself.
  88.  
  89. Memory trashing: VM really doesn't buy one protection against memory trashing.
  90. It tends to hide the problem, but eventually, even with VM, physical memory
  91. will get fragmented to a point where where won't be enough RAM to even swap.
  92. Of course, the above assumes that one doesn't swap out "public" memory, which
  93. would be necessary if one doesn't use separate memory maps for each process.
  94.  
  95. > >This scheme wouldn't keep everything from crashing, nor would it be 100%
  96. > >compatible, but I believe that it'd work and make the system much more
  97. > >stable without significant speed penalties.
  98.  
  99. > I also believe it might work.  It might also provide an upgrade path
  100. > to full memory protection later on.
  101.  
  102. Much later on.  Only after old software has aged to a point where no one uses
  103. them.
  104.  
  105.  
  106.